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Abstract 


As  military  tasks  become  more  and  more 
complex  budget  will  increasingly  be  limited  due 
to  the  national  economic  demands. 
Simultaneously  customer  specific  requirements 
on  near  real-time  processing,  high  availability, 
tailored  systems  and  integrability  into  NATO 
Interoperability  Management  Policy  are 
growing.  The  new  challenge  for  developers  and 
designers  on  the  one  hand  consists  in  meeting 
these  customer  requirements  and  in  offering 
modular  and  flexible  components  which  can  be 
integrated  into  legacy  systems.  On  the  other 
hand  development  costs  have  to  be  reduced  and 
the  time  for  assembling  and  delivering  systems 
have  to  be  shortened.  Therefore  systems  for 
military  purposes  have  to  integrate  and  have  to 
be  developed  with  more  and  more  extendable 
and  pre-built  standard  Commercial  Off-The- 
Shelf  (COTS)  components. 

As  a main  partner  of  the  German  armed  forces 
the  Rohde  & Schwarz  Radiomonitoring  and 
Radiolocation  Division  offers  customer  tailored 
and  component-based  systems  as  well  as  system 
integration  services  using  software  and  hardware 
COTS  components.  A lot  of  experience  has  been 
made  during  that  process  of  system 
development,  tailoring  and  integration  using 
COTS  products. 

The  Rohde  & Schwarz  radiomonitoring  systems 
may  be  seen  as  one  of  these  numerous  examples 
for  integrating  COTS  together  with  customer 
specific  components.  These  systems  also  show 
the  effects  the  use  of  COTS  products  may  have 
on  procurement  and  development  process  and 
system  architecture.  Radiomonitoring  systems 
by  Rohde  & Schwarz  represent  a concept  which 
meet  the  requirements  of  a state-of-the-art 
monitoring,  location  and  analysis  system.  They 
are  built  up  in  a highly  modular  way  and 
developed,  built  with  and  grouped  around 


typical  COTS  products  like  commercial  data 
bases,  interfaces  and  hardware  and  software 
modules.  The  software  architecture  and  the 
system  concept  provide  client-server 
functionality  and  links  to  complementary 
products  such  as  frequency  management 
software,  geographical  information  systems 
(GIS)  and  analysis  systems.  Custom-tailored 
solutions  are  manufactured  by  connecting 
standard  hardware  components  and  off-the- 
shelf,  tested  software  modules. 

Due  to  the  modular  concept  radiomonitoring 
systems  can  easily  be  upgraded  from  a compact 
to  a more  complex  and  interoperable  system. 
Standard  interfaces  allow  high  communication 
connectivity  within  local  or  world-wide 
networks  and  support  therefore  required 
interoperability  with  coalition  and  legacy 
systems. 

The  present  paper  describes  experiences  using 
COTS  components  and  forming  functional 
systems  from  software  and  hardware  integrants 
by  adapting  them  to  customer  specific 
requirements. 

1.  Introduction 

Due  to  the  progress  in  defense  technology 
modem  systems  for  military  purpose  are 
becoming  more  and  more  complex  and 
increasingly  expensive.  Numerous  components 
have  to  be  integrated  and  have  to  align  with 
requirements  like  integrability  into  legacy 
systems,  interoperability  and  system  capability. 
In  times  budget  is  usually  limited,  customers 
and  industry  have  two  different  aims.  Users  and 
customers  expect  cost-effective  systems  which 
cover  every  requirement  and  which  can  be 
integrated  into  an  existing  system  environment 
without  any  additional  costs.  System  designers 
and  developers  have  to  be  as  individual  as 
possible  to  give  the  customer  the  impression  of 
uniqueness.  Simultaneously  they  have  not  to 
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invent  really  new  systems  with  every 
commission  they  are  working  on.  System 
designers  and  developers  have  to  keep  a large 
number  of  industrial  and  specific  standards, 
protocols  and  techniques,  use  state-of-the  art 
methods,  tools  and  devices  each  one  of  which 
needs  to  become  familiar  with. 

They  therefore  integrate  more  and  more  off-the- 
shelf  products,  hardware  components  and 
devices  and  use  often  COTS  hardware  and 
software  components  to  keep  close  to  the 
customers  needs  or  to  reduce  the  effort  in  the 
own  software  development  process. 

But  with  the  use  of  third  party  products  - 
commonly  defined  as  COTS  components  - and 
the  integration  into  a system  miscellaneous 
problems  raise  than  building  a system  with 
completely  own  products  which  have  been 
developed  and  constructed  presently  or 
previously  internally  by  the  development 
organization  itself. 

Being  aware  of  these  problems  we  have  decided 
to  use  COTS  products  for  building  customer 
specific  and  tailored  systems  for  radio 
surveillance  and  monitoring  purposes  as  well  for 
military  as  civil  clients.  Rohde  & Schwarz  is 
looking  at  these  problems  from  the  integrators 
point  of  view,  who  is  using  COTS  products  to 
build  systems  rather  than  from  the  COTS 
builders  point  of  view  himself.  The  following 
paper  is  a report  about  the  experiences  we  have 
made,  concerning  integration  of  COTS  products 
in  systems  for  military  and  intelligence  purpose. 

Using  radiomonitoring  systems  as  an  example 
the  paper  describes  the  approach  and  the 
possible  points  to  bring  in  these  products. 
Starting  with  a basic  overview  on 
radiomonitoring  systems,  their  components, 
functionality  and  operational  structures  points  of 
attachements  will  be  shown  for  the  use  of 
COTS.  Experiences  out  of  the  development  and 
integration  process  will  be  outlined.  For  the 
process  itself  had  not  yet  been  finished  a final 
statement  about  the  success  can  not  been  made. 

2.  Definiton 

From  the  system  developers*  and  integrators1 
point  of  view  Commercial  Off-The-Shelf 
(COTS)  products  are  commonly  defined  [1,2,..] 
as  components  provided  by  a third-party  vendor. 
On  the  one  hand  they  may  be  used  for  the 
development  of  a system,  on  the  other  hand  as  a 
hardware  or  software  component  of  the  system 
itself.  By  definition  they  are  products  which 


have  to  be  accepted  as  they  are,  because  system 
builders  have  little  or  no  influence  on 
maintenance  and  evaluation.  Commonly  they 
behave  and  must  be  treated  like  a black  box. 
Another  characteristic  and  important  feature 
among  a lot  of  others  is  the  grade  of  evaluation 
and  the  wide  spectrum  of  customers  and  tasks 
they  are  designed  for. 

But  exactly  these  characteristics  cause  the 
different  set  of  problems  but  also  cause 
challenges  typical  system  integrators  have  to 
deal  with. 

3.  Background 

A first  step  in  designing  and  building  a system 
for  radio  surveillance  and  monitoring  by 
integrating  COTS  products  is  to  understand 
these  systems  and  its  functional  concurrence  in 
its  entirety.  The  system  technique  itself  and  the 
reproduction  of  procedural  steps  into  a modem 
workflow  is  nowadays  an  important  component 
of  state-of-the  art  system  integration.  But  not 
only  the  technical  design  of  these  system  change 
rapidly  also  the  required  and  realised  concepts 
are  modified.  Reasons  are  the  increasing 
development  and  improvements  in  defence  and 
communication  technology  on  the  one  hand  and 
in  user  requirements  like  efficency  and  user  - 
friendliness  growing  with  the  pretentious  tasks 
on  the  other  hand. 

Nowadays  realization  of  these  requirements  is 
nearly  unthinkable  without  using  modem 
computers,  user-specific  software  and  software 
tools.  For  several  reasons  - cost  efficiency, 
modularity,  reuseability,  standardization  - also 
COTS  products  play  an  important  role  within 
radio  monitoring  systems. 

Modem  radio  monitoring  systems  as  they  are 
developed  and  manufactured  by  Rohde  & 
Schwarz  consist  of  numerous  components  and 
subsystems  functionally  working  together. 
Components  of  each  systems  are  computer 
hardware  and  software  as  well  as  mainly 
computer-controlled  special  equipment  such  as 
antennas,  receivers,  analyzers  and  direction 
finders.  Mostly  they  are  systems  with  automated 
features  and  monitoring,  analysing  and 
visualization  capability.  They  contain 
distributed,  intelligent  subsystems  for 
measurement  and  location  of  electromagnetic 
emissions  working  close  together  within  the 
system.  Also  the  workflow  and  tasks  on  the 
entire  monitoring  process,  the  flow  of 
information  and  the  information  management 
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within  the  system  play  an  important  role  when 
mapping  them  into  a suitable  software. 
Measurement  results  may  be  stored  in  data  bases 
and  processed  by  powerful  1 computers  with 
analyzing  tools  and  reporting  features. 

In  the  term  of  radio  monitoring  all  processes  of 
acquisition,  monitoring  and  surveillance  are 
included.  This  comprises  also  automatic  an 
unmanned  surveillance  of  known  emitters  as 
well  as  identification  and  surveillance  of 
unknown  emitters  with  an  increasing  means  of 
analyzing,  post-processing  and  finally  reporting 
on  the  present  situation  up  to  the  presentation  of 
tactical  situations  for  the  decision  process  of 
military  leaders. 

3.1.  Tasks  and  possible  structure 
of  a radiomonitoring  system 

The  task  of  a modem  radiomonitoring  system 
within  the  complex  of  electromagnetic  emission 
is  showm  simplified  in  figure  1.  Herein  tasks  and 
functions  are  hierarchically  structured  from  the 
process  of  signal  collection  (acquisition,  search, 
monitor,  bear  and  locate  emitters),  over  pre- 
analyzing up  to  the  process  of  command  and 
control  including  reporting  and  processing. 


Within  the  whole  signal  scenario  and 
electromagnetic  spectrum  only  a small  part  of 
the  emission  has  to  be  acquired  and  monitored 
in  nearly  real  time.  But  exactly  this  part  has  to 
be  monitored  and  processed  very  fast.  Such  a 
task  may  only  be  solved  successfully  by  support 
of  computers  and  modem  information 
technology. 

As  in  many  other  systems  also  in 
radiomonitoring  systems  a lot  of  functions  and 
subsystems  are  working  close  together  and  may 
only  be  controlled  by  powerfull  computer  hard- 
and  software.  Thereby  the  operating  staff  shall 
be  relieved  in  routine  tasks  but  also  supported  in 
decisions  and  preparation  of  suitable  means. 

3.2.  Operational  aspects 

To  find  a possible  approach  of  COTS  products 
before  system  design  and  development  an  exact 
analysis  of  the  users  requirement  including  the 
used  workflow  and  operational  procedures  has 
to  be  done. 


Figure  1:  Task  structure  within  the  complex  of  electomagnetic  emission 
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Derived  from  the  basic  functions  of  a radio  many  tasks  have  been  automated  by  powerfull 
monitoring  system  like  computers  and  special  software  tools. 


• Receiving  operational  orders  and  translating 
into  tasks 

• Spectrum  surveillance  and  supervising  of 
known  emitters  and  frequencies.  Reporting 
upon  their  activity. 

• Searching,  identification  and  analyzation  of 
unknown  emitters  and  signals 

• recording  of  signals  and  analysis 

• emitter  location 

• tactical  evaluation  and  reporting 


The  following  considerations  are  based  on  the 
possible  structure  of  a modem  radiomonitoring 
system  as  shown  in  figure  2.  This  system  mainly 
consists  of  different  sensoric  components 
(antennas,  receivers),  signal  distribution  units, 
analyzers,  control  and  data  processing  units 
and  system  and  database  servers.  For  direction 
finding  and  bearing  purposes  remote  DF-sites 
may  be  attached  via  a modern  communication 
link. 


antenna  sw.tciiing  un  t 


monitoring 

receiver 
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receiver 
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decoder. 
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Figure  2:  Possible  structure  of  a modem  radio  monitoring  system 
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The  signals  of  interest  will  be  received  via  the 
according  antenna  and  distributed  to  the  dedicated 
receivers.  Then  a split  up  of  the  signal  onto  the 
different  hardware  tools,  like  demodulators, 
decoders  and  digital  signal  processors  follows. 
(The  tasks  of  these  subsystems  is  not  part  of  the 
presentation)  On  any  operator  console  different 
tasks,  control  (analysis  and  reporting)  functions 
are  realized.  The  allocation  of  tasks  and 
positions/consoles  usually  may  as  follows: 

Supervisor:  Control  and  tasking  of 

monitor/search  positions  and 
analyzer  positions.  Report  to 
higher  authorities  as  well  as 
receiving  orders  from  higher 
authorities. 

Monitoring  console: 

Signal  monitoring  and  recording 
in  a certain  frequency  band, 

creating  DF  requests  and 

reporting  on  signals  of  interest 

DF  console:  Search  and  location  of  emitters 

Analyzer  console: 

Analyzing  unidentified  and 

unknown  signals,  measurement  of 
signals. 

Parts  of  the  system  and  several  operator  consoles 
may  be  grouped  together  or  extended  according  to 
the  specific  function  or  the  requirements. 

The  software  used  within  the  system  has  to  be  of 
the  following  kind  according  to  the  tasks 

mentioned  above: 

• Control  software/drivers  for  specific  hardware 

• Analyzing  and  evaluation  software 

• Reporting  software 

• GIS  and  map  editing  software 

• Database 

• Communication  software 

• Translation  software. 

Recent  developments  in  computer  integration  and 
technology,  measurement  and  control  equipment 
as  well  as  in  COTS  products  nowadays  allows  an 
extensive  grade  of  automatiion.  Thereby 
processing  speed  and  efficiency  may  be  increased 
in  a perceptible  way  to  support  the  operator's 


work.  Simultaneously  costs  for  system 
development  and  integration  may  be  cut. 

3.3.  Functions  to  be  realized 

First  approaches  may  be  derived  from  the 
functional  diagram  of  a radiomonitoring  system. 
The  usability  of  common  hardware  products  as 
antennas,  receivers,  computers,  network  and 
infrastructure  components  are  obvious.  They  have 
to  be  clearly  defined  and  tested  for  their 
integrability. 

Furthermore  software  products  have  then  to  cover 
the  following  essential  tasks: 

• control  the  search  process  (i.e.  a channel  wise 
search  for  frequencies  controled  via  frequeny 
lists  etc.  generated  by  a database  referenced 
scan  orders)  by  a control  of  the  connected 
devices 

• control  of  the  identification  process  (i.e. 
forwarding  an  active  channel  to  the 
monitoring  receivers  triggered  by  certain 
events) 

• system  ressource  management 

• generating  automatic  requests  for  direction 
finding  according  to  pre-defined  events 

• support  of  signal  analysis,  demodulation  and 
decoding  (digital  signal  processing) 

• automatic  reporting  on  active 
channels/frequencies  nets  etc. 

• taking  over  of  DF  results  and  visualization  on 
maps  as  line  of  bearing 

• generating  map  based  status  reports. 


4.  Example  for  the  integration  of 
COTS  products 

Since  Rohde  & Schwarz  offers  turn-key  solutions 
for  radiomonitoring  systems,  we  have  experienced 
with  several  possibilities  to  bring  in  COTS 
products.  Their  effective  use  requires  a certain 
effort  to  identify  where  in  the  system  which 
COTS  products  can  be  used  in  a reasonable 
relationship  to  the  expense  the  system  integrators 
have.  Having  analyzed  the  functionality  of  the 
system,  the  kind  of  applicable  products  have  to  be 
defined  following  a catalogue  of  criterias  for 
component  selection. 

Figure  3 basically  gives  an  overview  on  the 
system  components  of  and  the  tasks  to  be  done  in 
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a radio  monitoring  system  in  connection  with  the 
information  and  processes  to  be  handled.  We  have 
used  this  diagram  to  make  an  estimation  where 
COTS  components  may  be  integrated  depending 
on  the  grade  of  specification. 

Looking  on  the  process  of  signal  acquisition, 
signal  processing  and  analyzing  several  in-house 
and  external  standard  products,  like  antenna 
systems,  receiver,  DSP’s  and  spectrum-analyzer 
fulfill  the  COTS  criteria.  They  are  not  specifically 
customer-designed  but  become  unique  from  the 
time  they  will  be  integrated  in  a system  and  have 
to  serve  for  specific  tasks.  From  the  moment  of 
adapting  these  products  to  specific  workflows  or 
customer  processes  they  have  to  be  controlled  by 
suitable  software. 

Mostly  results  of  software  controlled 
measurements  will  be  the  input  information  for 
the  following  hardware  and  have  to  be  handed 
over  to  another  device  via  a standard  interface  and 
a standard  format. 

Specific  algorithms  are  used  for  demodulation, 
decoding  or  signal  analysis.  Parts  of  the 
measurement  have  to  be  visualized  and  serve  for 
operators  decision.  In  this  part  of  the  system  the 
share  COTS  could  have  is,  from  our  experience 
relatively  small.  To  guarantee  an  optimum  of 
integration  numerous  device  drivers  and 
measurement  and  control  software  have  to  be 
adapted  to  the  customers  requirements.  Many 
specific  applications  resulting  out  of  the 
requirements  and  interfaces  to  almost  existing 
software  or  databases  keeping  the  customers 
datasets  is  a challenge  for  our  system  integrators. 
The  more  specific  and  unique  the  requirements 
are  the  harder  it  is  to  use  standard  applications  and 
COTS  products.  Therefore  we  decided  to  use 
COTS  products  only  as  tools  to  develop  our  own 
measurement  and  control  software  and  our  own 
device  drivers.  Besides  we  add  COTS  products 
like  GIS  software  and  relational  databases  to 
deliver  a system  covering  all  the  required 
functions. 

When  at  the  end  of  the  process  chain  the  hardware 
and  the  functions  within  a radio  monitoring 
system  become  more  common  and  the 
preprocessing  provides  more  standard  format 
outputs  an  integration  of  COTS  products  is 
simplified. 

To  generate  tactical  evaluations  and  status  reports 
out  of  the  condensed  outputs  of  the  sensoric  and 
signal  processing  hardware  a set  of  standard 
applications  exist  which  can  be  used  for  these 


purposes.  One  example  is  reporting  software 
which  is  adaptable  to  standard  file  formats  and 
offer  a standard  interface  to  many  third-party 
COTS  products  like  Office  software,  GIS 
applications  and  relational  or  desktop  databases. 
To  forward  these  reports  we  try  to  integrate  even 
standard  applications  (eMail  etc.)  running  on 
standard  COTS  hardware.  From  the  hardware 
perspective  also  for  the  interconnection  of  the 
several  operator  consoles  and  sites  via  LAN  or 
WAN  regular  network  and  communication 
components  can  be  integrated. 

To  sum  up  it  can  be  said  that  in  radio  monitoring 
systems  COTS  products  are  easy  to  integrate  if 
the  task  of  that  product  keeps  as  common  to 
standards  and  as  simple  as  possible.  As  soon  as 
the  task  or  part  of  the  system  becomes  specific  or 
complex  integration  and  use  of  COTS  products 
becomes  difficult  due  to  the  characteristics  of 
COTS.  Adapting  COTS  soft-  and  hardware  to  the 
desired  functionality  and  interfaces  of  rather 
complex  systems  is  often  more  difficult  and 
ineffectice  than  to  generate  own  software  in  small 
edition. 
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Figure  3: 


Possible  cooperation  of  system  components,  processes  and  information  as  a basic  for  COTS 
integration  possibilities 
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5.  Experiences  in  development 
and  implementation  using 
COTS  products 

Taking  into  account  the  basic  structure  of  a radio 
monitoring  system  as  described  in  chapter  3,  its 
operational  aspects  and  the  possibilities  to  bring  in 
COTS  we  have  identified  two  different 
perspectives  to  face  that  challenge.  The  system 
integrator's  view  is  more  based  on  the  decision 
how  and  where  in  the  system  COTS  products  may 
be  integrated  in  the  most  cost  effective  way 
whereas  the  developers  view  reflects  the  possible 
use  of  COTS  tools  and  the  question  how  to 
generate  a COTS  product  itself  to  keep  the  effort 
for  development  and  reuse  as  small  as  possible. 
Common  to  both  views  is  that  COTS  products 
have  certain  properties  which  affect  the  system 
and  its  functionality  and  therefore  have  to  be 
considered  in  time. 

After  a first  process  of  determining  the  applicable 
COTS  products  the  most  available  ones  have  to  be 
chosen  following  certain  selecting  criteria. 

5.1.  Example  of  using  COTS  for 
software  development 

When  we  have  recognized  the  basic  useability  of 
COTS  for  a customer  specific  radio  monitoring 
system  we  looked  for  a suitable  project  to  start 
with.  Within  the  complexity  of  measurement 
control,  monitoring,  reporting  and  evaluation 
software  we  picked  out  the  integration  of  two 
software  products.  As  a result  of  the  process  of 
integration  a new,  modular  built  up  software 
should  be  created  with  a unique  kernel  and 
different,  preferebly  COTS  based  modules. 

The  first  software  is  mainly  determined  for  the 
civil  client.  It  is  a radio  and  spectrum  monitoring 
software  package  which  is  used  to  maintain  the 
quality  of  the  spectrum  by  detecting  interferences 
from  licensed  and  non-licensed  users  (national 
and  international)  and  man-made  interferences. 
This  software  is  part  of  the  radio  monitoring 
systems  Rohde  & Schwarz  is  building  for 
different  customers  like  public  authorities  and 
frequency  allocation  boards. 

The  relevant  rules  and  recommendations  for 
spectrum  monitoring  and  spectrum  management 
and  the  related  software  behind  are  from  the 


International  Telecommunication  Union  (ITU), 
Geneva. 

Due  to  the  above  mentioned  customers  as 

• broadcast  and  TV  organisations 

• ATC  (Air  Traffic  Control)  organisations 

• frequency  regulation  authorities 

the  tasks  and  features  vary  from 

• long  term  monitoring  of  transmitters 

• checking  of  optimal  coverage 

• providing  interference  free  operations 

• getting  direction  / location  of  aircrafts  / 
unwanted  emissions 

• checking  of  frequency  spectrum 
up  to 

• planning  of  communication  links  and 
frequencies. 

Especially  for  the  non-civil  customers  like 

• defence  forces 

• security  organisations 
and 

• law  enforcement  agencies 

another  radio  monitoring  software  was  originally 
designed  for. 

These  customers  set  the  focus  on  tasks  like 

• searching  for  known/unknown  signals 

• monitoring  frequencies 

• identifying  signal  sources 

• DF  and  locating  signal  sources 

• getting  information  about  communication 
nets  as 

• station  identifiers  (call  signs  / names  / 
numbers) 

• transmission  start/stop  time 

• directions  / locations 

• signal  contents 

• technical  signal  parameters... 

• evaluation  of  monitoring  results  and 
reporting. 

The  aim  behind  the  development  was  to  build  a 
product  which  offers  the  common  features  of  both 
applications  and  provides  enough  modularity  to 
cover  the  civil  and  military  market  with  additional 
specific  extensions. 
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By  creating  own  off-the-shelf  modules,  reducing 
production  and  delivery  time,  overlaying  an 
expandable  strategy  and  designing  for  stationary, 
(semi)mobile  and  network  use,  the  product  should 
have  enough  flexibility  to  serve  also  a wide  band 
client. 

5.2.  Defining  the  requirements 

A first  step  to  transform  the  idea  into  a practicable 
solution  was  to  define  the  basic  requirements  and 
to  specify  the  key  features  as 

• use  of  a flexible  and  modular  concept  which 
allows  easy  adaption  to  new  operational 
procedures 

• separation  of  functionality  and  desktop 

• definition  of  external  interfaces 

• easy  installation  and  maintain 

• keeping  low  development  costs  and  time. 

The  functional  and  operational  requirements  were 
gathered  in  a very  high  level  of  abstraction  and 
should  help  us  to  define  the  context  in  which  the 
software  will  be  used  and  the  major  functions  that 
it  will  provide. 

The  fundamential  architecture  behind  should  keep 
close  to  a layer  based  model  and  contain  clearly 
defined  interfaces  to  relational  or  desktop 
databases,  networks,  devices  and  users  (MMI). 
Besides  it  should  reflect  the  major  requirements 
within  functionally  grouped  subsystems  and 
modules. 


5.3.  Setting  up  the  phases 

Once  selected  the  suitable  COTS  tools  we  started 

to  divide  the  process  into  several  phases  according 

to  common  rules  for  software  development: 

• Analysis  phase  (by  using  use  cases  to  capture 
the  customers  requirements  and  transform 
them  into  software  functions) 

• Design  phase  (using  class  diagrams) 

• Implementation  phase  (code  generation  with 
C++,  verification  and  validation) 

• Test  phase  (module,  subsystem  and  interface 
testing  using  specific  test  tools). 


5.4.  The  experiences 

The  first  phase  of  prototype  implementation 
consists  of  building  a basic  subsystem  as  a 
functional  kernel  covering  the  different 
customers1  requirements.  Specific  add-ons  should 
allow  us  to  customize  the  software  due  to  the 
specific  demands. 
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third  party  software  (GIS,  RDBMS,  report  tools...) 


Within  that  subsystem  we  started  with  a standard 
device  driver  module  for  receiver  control  with 
interfaces  to  hardware  and  GUI  components  and  a 
LAN  based  audio  recording/playback  module 
with  interfaces  to  a COTS  database. 

With  the  use  of  standard  products  like  Use  Cases, 
class  libraries,  standard  software  development 
tools  and  according  to  object  oriented  software 
development  standards  we  tried  to  build  a first 
prototype.  It  should  provide  a basic  functionality 
and  contain  almost  sufficient  functionality  to 
interact  with  the  according  hardware  devices 
within  the  radio  monitoring  system. 

Already  during  the  phases  of  development 
experiences  described  in  other  publications  [1,2] 
could  be  confirmed.  A lot  of  properties  of  COTS 
supported  software  development  and  integration 
of  COTS  components  became  obvious.  Most  of 
the  experiences  we  dealt  with  concern  the 
interface  between  own  modules  and  source  code 
and  COTS  components. 

Because  of  the  fast  evolution  of  COTS  products  a 
clearly  defined  interface  is  absolutely  necessary. 
The  architecture  of  the  generated  software  must 
allow  an  isolation  of  COTS  products.  Otherwise 
an  expansion  of  the  final  product  or  a complete 
substitution  of  COTS  parts  is  nearly  impossible. 
One  of  the  main  problem  we  had  to  deal  with  was 
the  near  real  time  processing  of  audio  data  within 
the  network.  Due  to  the  different  requirements  of 
the  customer  to  the  system  performance  we  had  to 
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try  several  versions  of  drivers  to  reduce  the  delay 
time  to  a minimum. 

Furthermore  clearly  defined  and  possibly  standard 
interfaces  makes  developers  and  finally  customers 
independent  from  proprietery  COTS  products.  As 
an  example  we  used  class  libraries  from 
Roughware  for  Windows  NT  ™and  Unix  systems 
to  be  open  for  different  operation  platforms  and  to 
reduce  the  development  process  for  both  systems. 
SQL  and  ODBC  interfaces  allow  access  and  data 
transfer  from/to  external  databases  such  as  Oracle 
or  MS  Access.  The  use  of  customer  specific  data 
may  be  guaranteed. 

Of  essential  importance  was  the  test  of  the  used 
and  generated  modules  with  test  tools. 

Derived  from  these  experiences  we  figured  out  the 
major  steps  to  follow  when  using  COTS 
components  in  our  radio  monitoring  systems. 

The  qualification  process  starts  with  identifying 
the  properties  of  a component  and  its  qualification 
for  the  intended  requirement.  This  includes  items 
as  functionality,  use  of  standard  interfaces, 
reliability  and  exchangeability  in  case  of  adaption 
to  changed  requirements  etc..  Especially  for  the 
process  of  development  the  testing  and  reusing  is 
another  major  factor  for  the  use  of  tools  and 
components  as  part  of  a whole. 

But  nevertheless  also  external  dependencies 
played  an  important  role  when  we  decided  for 
certain  COTS  components.  Because  of  the 
frequently  update  process  of  COTS,  integrators 
have  to  face  additional  risks  when  using  these 
products.  Due  to  the  life  cycle  of  our  products  a 
simple  update  of  a single  component  like  an 
upgrade  of  a new  data  base  version  is  realistic. 
But  this  may  have  other  effects  within  the  whole 
system  and  result  in  malfunctions  especially  in 
time-  and  data-critical  applications. 

Through  the  process  of  assembling  COTS  into  our 
own  software  we  have  seen  that  the  interface  and 
data  exchange  structure  is  almost  important.  This 
may  influence  the  portability  and  interoperability 
of  the  system.  Here  some  styles  cristallized  like: 

• The  centralized  style  which  is  based  on  a 
common  database  and  shares  information  via 
this  information  pool. 

• The  message  handling  style  in  which  each 
component  has  its  own  data  store  and  data 
transfer  is  coordinated  by  messages  or 
procedure  calls  of  the  components. 


• The  object  oriented  style  in  which  Broker 
provides  mechanism  for  object  location  and 
activation. 

Considering  the  characteristic  customer  who 
already  has  long  grown  centralized  data  like 
frequency  or  operational  data  bases  we 
concentrated  on  the  first  style. 

From  the  aspect  of  exchangeability  we  had  to  be 
careful  with  the  simplistic  view  of  upgrading  and 
replacing  components  during  the  phase  of 
development  and  integration.  Replacement  of 
components  often  was  a very  difficult  and  time- 
consuming  process  due  to  the  mostly  non- 
identical successors,  different  behaviour  and 
resulting  test  phase. 

As  a result  of  our  COTS  experiences  we  have 
recognized  that  a structured  planning  and 
definition  of  the  use  of  COTS  and  its  purpose  in 
the  system  makes  the  whole  process  of 
development  and  integration  easier.  Besides  the 
questions  for  qualification,  reuse,  functionality 
and  interoperability  also  long  term  considerations 
and  usage  play  an  important  role. 

The  costs  often  considered  as  one  main  factor  for 
using  low  price  COTS  instead  of  own  products  is 
on  the  second  view  not  as  significant  as  it  was 
originally.  During  the  implememtation  of  the  first 
systems  additional  costs  for  customer  training, 
maintenance,  licensing  and  error  tracking  and 
correction  occured.  This  reduces  the  price 
advantage  of  COTS  products  often  to  a minimum. 
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6.  Conclusion 

A lot  of  properties  of  COTS  supported  software 
development  and  integration  of  COTS 
components  became  obvious  during  our  software 
project.  As  a conclusion  the  experiences  are 
summed  up  thematically  grouped  from  integration 
via  coding  to  maintenance  and  testing. 

Integrability: 

• When  integrating  COTS  products  a reasonable 
relation  between  effort  of  integration  and 
adaption  of  own  products  and  the  requirements 
one  wants  to  cover  with  COTS  must  exist 
(unfortunately  this  is  not  foreseeable  when 
starting  the  development  and  deciding  for  a 
product). 

• Furthermore  clearly  defined  and  possibly 
standard  interfaces  makes  developers  and  finally 
customers  independent  from  proprietery  COTS 
products.  As  an  example  we  used  class  libraries 
from  Roughware  for  Windows  NT  ™ and  Unix 
systems  to  be  open  for  different  operation 
platforms  and  to  reduce  the  development  process 
for  both  systems.  SQL  and  ODBC  interfaces 
allow  access  and  data  transfer  ffom/to  external 
databases  such  as  Oracle  or  MS  Access.  The  use 
of  customer  specific  data  may  be  guaranteed. 

• Because  of  the  fast  evolution  of  COTS  products 
seperabihty  is  absolutely  necessary  at  each  time. 
The  architecture  of  the  generated  software  must 
allow  an  isolation  of  COTS  products.  Otherwise 
an  expansion  of  the  final  product  or  a complete 
substitution  of  COTS  parts  is  nearly  impossible. 

Coding: 

• Because  of  the  evolution  process  of  COTS  the 
market  requires,  the  own  coding  effort  has  to  be 
aware  of  this  evolution  and  to  watch  for  new 
version  and  releases  which  could  suddenly 
become  interoperable  with  the  code  the  devloper 
has  written  yet. 

• COTS  components  affect  the  functionality  of  the 
whole  software  for  instance  in  time-critical 
applications  (essentially  when  time  errors  occur 
while  one  device  or  module  is  waiting  for  data 
of  another  application). 

• Once  the  system  integrator  has  decided  to  use  a 
certain  COTS  product,  a necessary  upgrade  of 
own  products  has  to  wait  unless  also  the  COTS 
product  will  be  upgraded  too.  This  reduces  the 
evaluation  process  of  the  own  product. 


But  we  also  made  the  positive  experience  that 
several  tools  support  the  development  process  and 
COTS  may  extend  the  functionality  of  the  own 
product  by  extending  its  possibility  (like 
evaluation,  map  processing  and  GIS  software) 

Maintenance  and  testing: 

• Because  of  the  fast  evolution  of  COTS  software 
a mamtenace  is  rather  difficult  and  the  system 
integrator  has  to  keep  enough  qualified  personal 
on  hand  to  be  able  to  integrate  and  use  the 
current  version. 

• Furthermore  a configuration  management  is 
absolutely  necessary  to  cover  all  releases 

• Integrators  and  developers  should  use 
appropriate  test  tools  during  the  development  to 
guarantee  the  interoperability  to  their  piece  of 
software  at  any  time. 
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